…th-fix, r=kobzol

Fix profiler_builtins build script to handle full path to profiler lib

LLVM_PROFILER_RT_LIB may be set to an absolute path (e.g., in Fedora builds), but `-l` expects a library name, not a path. After rust-lang#138273, this caused builds to fail with a "could not find native static library" error.

This patch updates the build script to split the path into directory and filename, using `cargo::rustc-link-search` for the directory and `cargo::rustc-link-lib=+verbatim` for the file. This allows profiler_builtins to correctly link the static library even when an absolute path is provided.

…=tgross35,joboet

Use `with_native_path` for Windows

Ideally, each platform should use their own native path type internally. This will, for example, allow passing a UTF-16 string directly to `std::fs::File::open` and therefore avoid the need for allocating a new null-terminated wide string. However, doing that for every function and platform all at once makes for a large PR that is way too prone to breaking. So this just does some of the Windows parts.

As with the previous Unix PR (rust-lang#138832) this is intended to be merely a refactoring so I've avoided anything that may require more substantial changes.

Move `args` into `std::sys`

Move platform definitions of `args` into `std::sys`, as part of rust-lang#117276.

cc ``@joboet``

… r=dtolnay

Move `select_unpredictable` to the `hint` module

There has been considerable discussion in both the ACP (rust-lang/libs-team#468) and tracking issue (rust-lang#133962) about whether the `bool::select_unpredictable` method should be in `core::hint` instead.

I believe this is the right move for the following reasons:
- The documentation explicitly says that it is a hint, not a codegen guarantee.
- `bool` doesn't have a corresponding `select` method, and I don't think we should be adding one.
- This shouldn't be something that people reach for with auto-completion unless they specifically understand the interactions with branch prediction. Using conditional moves can easily make code *slower* by preventing the CPU from speculating past the condition due to the data dependency.
- Although currently `core::hint` only contains no-ops, this isn't a hard rule (for example `unreachable_unchecked` is a bit of a gray area). The documentation only status that the module contains "hints to compiler that affects how code should be emitted or optimized". This is consistent with what `select_unpredictable` does.

* Update comments to clarify the usage of zero as an indication for default stack size configuration
* Adjust conditional compilation to reflect the changes in stack size handling for the NuttX platform

This change improves clarity and consistency in stack size configuration across platforms.

Signed-off-by: Huang Qi <[email protected]>

…enton

Rollup of 10 pull requests

Successful merges:

 - rust-lang#138972 (std: Fix build for NuttX targets)
 - rust-lang#139177 (Use -C target-cpu=z13 on s390x vector test)
 - rust-lang#139511 (libtest: Pass the test's panic payload as Option instead of Result)
 - rust-lang#139605 (update ```miniz_oxide``` to 0.8.8)
 - rust-lang#139618 (compiletest: Make `SUGGESTION` annotations viral)
 - rust-lang#139677 (Fix profiler_builtins build script to handle full path to profiler lib)
 - rust-lang#139683 (Use `with_native_path` for Windows)
 - rust-lang#139710 (Move `args` into `std::sys`)
 - rust-lang#139721 (End all lines in src/stage0 with trailing newline)
 - rust-lang#139726 (Move `select_unpredictable` to the `hint` module)

r? `@ghost`
`@rustbot` modify labels: rollup

According to the docs in `Command::output`:

> By default, stdout and stderr are captured (and used to provide the
resulting output). Stdin is not inherited from the parent and any attempt
by the child process to read from the stdin stream will result in the
stream immediately closing.

This was being violated by UEFI which was inheriting stdin by default.

While the docs don't explicitly state that the default should be NULL,
the behaviour seems like reading from NULL.

UEFI however, has a bit of a problem. The `EFI_SIMPLE_TEXT_INPUT_PROTOCOL`
only provides support for reading 1 key press. This means that you
either get an error, or it is assumed that the keypress was read
successfully. So there is no way to have a successful read of length 0.
Currently, I am returning UNSUPPORTED error when trying to read from
NULL stdin. On linux however, you will get a read of length 0 for Null
stdin.

One possible way to get around this is to translate one of the UEFI
errors to a read 0 (Maybe unsupported?). It is also possible to have a
non-standard error code, but well, not sure if we go that route.

Alternatively, if meaning of Stdio::Null is platform dependent, it
should be fine to keep the current behaviour of returning an error.

Signed-off-by: Ayush Singh <[email protected]>

Allows implementing Stdio::Null for Command in a deterministic manner.

Signed-off-by: Ayush Singh <[email protected]>

Stdio::MakePipe is not supported.

For Stdio::Null, return UNSUPPORTED. This is treated as read(0).
Additionally, have infinte loop on the notify function to prevent
wait_for_key from returning.

Signed-off-by: Ayush Singh <[email protected]>

The only differences between these implementations are that Unix uses
relaxed ordering, but Hermit uses acquire/release, and Unix truncates
`argv` at the first null pointer, but Hermit doesn't. Since Hermit aims
for Unix compatibility, unify it with Unix.

…ross35,RalfJung,WaffleLapkin

Initial `UnsafePinned` implementation [Part 1: Libs]

Initial libs changes necessary to unblock further work on [RFC 3467](https://rust-lang.github.io/rfcs/3467-unsafe-pinned.html).
Tracking issue: rust-lang#125735

This PR is split off from rust-lang#136964, and includes just the libs changes:
- `UnsafePinned` struct
- private `UnsafeUnpin` structural auto trait
- Lang items for both
- Compiler changes necessary to block niches on `UnsafePinned`

This PR does not change codegen, miri, the existing `!Unpin` hack, or anything else. That work is to be split into later PRs.

---

cc ``@RalfJung`` ``@Noratrieb``

``@rustbot`` label F-unsafe_pinned T-libs-api

Avoid cloning in `Cloned<I>` or copying in `Copied<I>` when elements are
only needed by reference or not at all. There is already some precedent
for this, given that `__iterator_get_unchecked` is implemented, which
can skip elements. The reduced clones are technically observable by a
user impl of `Clone`.

Signed-off-by: xizheyin <[email protected]>

If you want to logically split an iterator after `n` items, you might first
discover `take`. Before this change, you'd find that `take` consumes the
iterator, and you'd probably be stuck. The answer involves `by_ref`, but that's
hard to discover, especially since `by_ref` is a bit abstract and `Iterator`
has many methods.

After this change, you'd see the example showing `take` along with `by_ref`,
which allows you to continue using the rest of the iterator. `by_ref` had a
good example involving `take` already, so this change just duplicates that
existing example under `take`.

Also update the symbol names as items have moved around a bit. The actual
name isn't that important, it just needs to be unique. But for debugging
it can be useful for it to point to the right place.

* "while until either" could also be changed to "for a while until either", but I just deleted "while".
* fixed sentence with incorrect "at" and "has/have".
* linked [*currently allocated*] similar to other methods.

Report line number of test when should_panic test failed

Closes rust-lang#137405

---

try-job: x86_64-gnu-llvm-19-3
try-job: test-various

…iaskrgr

Rollup of 8 pull requests

Successful merges:

 - rust-lang#139127 (Fix up partial res of segment in primitive resolution hack)
 - rust-lang#139392 (Detect and provide suggestion for `&raw EXPR`)
 - rust-lang#139767 (Visit place in `BackwardIncompatibleDropHint` statement)
 - rust-lang#139777 (Remove `define_debug_via_print` for `ExistentialProjection`, use regular structural debug impl)
 - rust-lang#139796 (ptr docs: add missing backtics around 'usize')
 - rust-lang#139801 (Add myself to mailmap)
 - rust-lang#139804 (use `realpath` in `bootstrap.py` when creating build-dir)
 - rust-lang#139807 (Improve wording of post-merge report)

r? `@ghost`
`@rustbot` modify labels: rollup

This change maps the EOPNOTSUPP errno value (95) to std::io::ErrorKind::Unsupported in the decode_error_kind function for Unix platforms. Previously, it was incorrectly mapped to ErrorKind::Uncategorized.

Fixes rust-lang#139803

…, r=joboet

Avoid unused clones in `Cloned<I>` and `Copied<I>`

Avoid cloning in `Cloned<I>` or copying in `Copied<I>` when elements are only needed by reference or not at all. There is already some precedent for this, given that `__iterator_get_unchecked` is implemented, which can skip elements. The reduced clones are technically observable by a user impl of `Clone`.

r? libs-api

approved in ACP rust-lang/libs-team#554

Ref: rust-lang#126840 (comment)

…ct, r=compiler-errors,oli-obk,RalfJung

Enable contracts for const functions

Use `const_eval_select!()` macro to enable contract checking only at runtime. The existing contract logic relies on closures, which are not supported in constant functions.

This commit also removes one level of indirection for ensures clauses since we no longer build a closure around the ensures predicate.

Resolves rust-lang#136925

**Call-out:** This is still a draft PR since CI is broken due to a new warning message for unreachable code when the bottom of the function is indeed unreachable. It's not clear to me why the warning wasn't triggered before.

r? ```@compiler-errors```

…oboet

std: sys: process: uefi: Use NULL stdin by default

According to the docs in `Command::output`:

> By default, stdout and stderr are captured (and used to provide the
resulting output). Stdin is not inherited from the parent and any attempt by the child process to read from the stdin stream will result in the stream immediately closing.

This was being violated by UEFI which was inheriting stdin by default.

While the docs don't explicitly state that the default should be NULL, the behaviour seems like reading from NULL.

UEFI however, has a bit of a problem. The `EFI_SIMPLE_TEXT_INPUT_PROTOCOL` only provides support for reading 1 key press. This means that you either get an error, or it is assumed that the keypress was read successfully. So there is no way to have a successful read of length 0. Currently, I am returning UNSUPPORTED error when trying to read from NULL stdin. On linux however, you will get a read of length 0 for Null stdin.

One possible way to get around this is to translate one of the UEFI errors to a read 0 (Maybe unsupported?). It is also possible to have a non-standard error code, but well, not sure if we go that route.

Alternatively, if meaning of Stdio::Null is platform dependent, it should be fine to keep the current behaviour of returning an error.

cc ```@nicholasbishop``` ```@dvdhrm```

…=tgross35

std: add Output::exit_ok

approved in ACP rust-lang/libs-team#554

Tracking issue: rust-lang#84908

Proc macro span API redesign: Replace proc_macro::SourceFile by Span::{file, local_file}

Simplification/redesign of the unstable proc macro span API, tracked in rust-lang#54725:

Before:

```rust
impl Span {
    pub fn line(&self) -> usize;
    pub fn column(&self) -> usize;
    pub fn source_file(&self) -> SourceFile;
}

#[derive(Clone, Debug, PartialEq, Eq)]
pub struct SourceFile { .. }

impl !Send for SourceFile {}
impl !Sync for SourceFile {}

impl SourceFile {
    pub fn path(&self) -> PathBuf;
    pub fn is_real(&self) -> bool;
}
```

After:

```rust
impl Span {
    pub fn line(&self) -> usize;
    pub fn column(&self) -> usize;
    pub fn file(&self) -> String; // Mapped file name, for display purposes.
    pub fn local_file(&self) -> Option<PathBuf>; // Real file name as it exists on disk.
}
```

This resolves the last blocker for stabilizing these methods. (Stabilizing will be a separate PR with FCP.)

std/thread: Use default stack size from menuconfig for NuttX

* Update comments to clarify the usage of zero as an indication for default stack size configuration
* Adjust conditional compilation to reflect the changes in stack size handling for the NuttX platform

This change improves clarity and consistency in stack size configuration across platforms.

…tolnay

Fix: Map EOPNOTSUPP to ErrorKind::Unsupported on Unix

This change maps the EOPNOTSUPP errno value (95) to std::io::ErrorKind::Unsupported in the decode_error_kind function for Unix platforms. Previously, it was incorrectly mapped to ErrorKind::Uncategorized.

Fixes rust-lang#139803

…=jhpratt

Basic tests of MPMC receiver cloning

Ref: rust-lang#126840 (comment)

…=Amanieu

Rename `*Guard::try_map` to `filter_map`.

Rename `std::sync::*Guard::try_map` to `filter_map`.

1. Analogous to `std::cell::Ref(Mut)::filter_map`.
2. Doesn't imply `Try` genericizability.

r? `@Amanieu` (or other T-libs-api)

Tracking issue for `mapped_lock_guards`: rust-lang#117108

…able, r=workingjubilee

Stabilize `select_unpredictable`

FCP completed in tracking issue rust-lang#133962.

…kingjubilee

Change signature of File::try_lock and File::try_lock_shared

These methods now return Result<(), TryLockError> instead of Result<bool, Error> to make their use less errorprone

These methods are unstable under the "file_lock" feature. The related tracking issue is rust-lang#130999 and this PR changes the signatures as discussed by libs-api: rust-lang#130994 (comment)

…in-std-io-pipe-docs, r=tgross35

Use present indicative tense in std::io::pipe() API docs

The inline documentation for all other free functions in the `std::io` module use the phrase "creates a" instead of "create a", except for the currently nightly-only `std::io::pipe()` function. This commit updates the text to align with the predominant wording in the `std::io` module.

I recognize this PR is quite a minuscule nitpick, so feel free to ignore and close if you disagree and/or there are bigger fish to fry. Thanks in advance! :smile:

Relates to rust-lang#127154.

…ypo, r=cuviper

doc(std): fix typo lchown -> lchmod

chown is irrelevant here, as this function does not affect file ownership.  chmod is the correct function to reference here.